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Incorporation By Reference 

2 The Java™ Language Specification (Sun Microsystems, Inc., 1 993-95), (hereinafter referred 

3 to as the "Java language specification") a copy of which is attached hereto as Appendix A, 

4 incorporated herein by reference. 

5 The Java Virtual Machine Specification (Sun Microsystems, Inc., 1993-95), (hereinafter 

6 referred to as the "Java virtual machine specification") a copy of which is attached hereto as Appendix 
flk B, incorporated herein by reference. 

% Ann WoUrath, et al., "A Distributed Object Model ft)r Java™," an unpublished paper attached 

® hereto as Appendix C, incorporated herein by reference. 

^ M U. S. Patent Application Ser. No. 68l(p3(p^ H bH, filed on even date herewith in the 

IJl. names of James H. Waldo, Krishna Bharat and Roger Riggs, and entitled " System And Method For 

IS Generating Identifiers For Uniquely Identifying Object Types For Objects Used In Processing Of 

U ii Object-Oriented Programs And The Like" ^A^yrBo^rt^orPie^t) (hereinafter identified as the 

M "Waldo, et al., patent application."), incorporated herein by reference. 

1 5 Field Of The invention 



1 6 The invention relates generally to the field of digital computer systems, and more particularly 

17 to systems and methods for facilitating the invocation by a program being processed by a computer 

18 in one address space, of processing of methods and procedures in another address space, which may 

19 be implemented either on the same computer or on another computer. The invention particularly 

20 provides a system and method for obtaining and dynamically loading "stub" information which 

21 fecilitates invocation by a program operating in one address space of a remote method or procedure 

22 in another address space, and possibly on another computer. 
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1 Background Of The Invention 

2 In modem "enterprise" computing, a number of personal computers, workstations, and other 

3 devices such as mass storage subsystems, network printers and interfaces to the public telephony 

4 system, are typically interconnected in one or more computer networks. The personal computers and 

5 workstations are used by individual users to perform processing in connection with data and programs 

6 that may be stored in the network mass storage subsystems. In such an arrangement, the personal 

7 computers/workstations, operating as clients, typically download the data and programs from the 
^ network mass storage subsystems for processing. In addition, the personal computers or 
g> workstations will enable processed data to be uploaded to the network mass storage subsystems for 
W storage, to a networic printer for printing, to the telephony interfece for transmission over the public 
li telephony system, or the like. In such an arrangement, the network mass storage subsystems, 
U network printers and telephony interface operate as servers, j^nce they are avmlable to service 
13 requests from all of the clients in the network. By organizing the network in such a manner, the 
B servers are readily available for use by all of the personal computers/workstations in the network. 
Jft Such a network may be spread over a fairly wide area, with the personal computers/workstations 
|5 being interconnected by communication links such as electrical wires or optic fibers. 

17 In addition to downloading information from servers for processing, a client, while processing 

18 a program, can remotely initiate processing by a server computer of particular routines and 

19 procedures (generally "procedures"), in connection with certain "parameter" information provided 

20 by the client. After the server has processed the procedure, it will provide results of its processing 

21 to the client, which the client may thereafter use in its processing operations. Typically in such 

22 "remote procedure calls" the program will make use of a local "stub" which, when called, transfers 

23 the request to the server which implements the particular procedure, receives the results and provides 

24 them to the program. Conventionally, the stub must be eq^ilecTyith the program, in which case 

25 the information needed to call the remote procedure must be determined at compile time, rather than 

26 at the time the program is run. Since the stub available to the client's programs is static, it may be at 
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1 best the closest that can be determined should be provided for the program when it (the program) is 

2 compiled. Accordingly, errors and inefficiencies can develop due to mismatches between the stub 

3 that is pro\dded to a program and the requirements of the remote procedure that is called when the 

4 program is run. 

5 Summary Of The Invention 

6 The invention provides a new and improved system and method for facilitating the obtaining 

7 and dynamic loading of a stub provided to enable a program operating in one address space to 
^ remotely invoke processing of a method or procedure in another address space, so that the stub can 

be baded by the program when it is run and needed, rather than being statically determined when the 

W program is compiled. Indeed, the stub that is loaded can be obtained from the resource providing the 

t| remote method or procedure, and so it (the stub) can exactly define the invocation requirements of 

§2 the remote method or procedure. Since the stub can be located and dynamically loaded while the 

O program is being run, rather that being statically determined when the program is compiled, run-time 

llj errors and ineflBciencies which may result from mis-matches between the stub that is provided and 

the requirements of the remote method or procedure that is invoked can be minimized. 

16 In brief summary, the invention provides a stub retrieval and loading subsystem for use in 

17 connection with a remote method invocation system. The stub retrieval and loading subsystem 

18 controls the retrieval and loading of a stub for a remote method, into an execution envh'onment, to 

1 9 facilitate invocation of the remote method by a program executing in the execution environment. The 

20 stub retrieval subsystem includes a stub retriever for initiating a retrieval of the stub and stub loader 

21 for, when the stub is received by the stub retriever, loading the stub into the execution environment, 

22 thereby to make the stub available for use in remote invocation of the remote method. In one 

23 embodiment, the stub retrieval and loading subsystem effects the retrieval and loading for a program 

24 operating in one address space provided by one computer, of stub class instances to effect the remote 

25 invocation of methods which are provided by objects operating in another address space, which may 
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1 be provided by the same computer or a diflferent computer. In that same embodiment, the stub 

2 retrieval and loading subsystem effects the retrieval and loading of a stub class instance when the 

3 remote object is referenced, although in other embodiments retrieval and loading may be effected 

4 when the remote method is invoked. 

5 Brief Description Of The Drawings 

6 This invention is pointed out with particularity in the appended claims. The above and further 

7 advantages of this invention may be better understood by referring to the following description taken 
S in conjunction with the accompanying drawings, in which: 

3| FIG. 1 is a function block diagram of a computer network including an arrangement 

t4 constructed in accordance with the invention for facilitating the obtaining, dynamic loading and use 

S of "stub" information to enable a program operating in one address space to invoke processing of a 

to remote method or procedure in another address space; 

fi FIGs. 2-a nd ^ are flow charts depiaing the operations performed by the arrangement depicted 

in FIG. 1, which is usefid in understanding the invention, with FIG: 2 depictmg operations performed 
5 ^ ' /I ^ yx&s. 3/W3^ 

^ in connection with obtaining and dynamic loading of the stub information and F IG. 3 depicting 

16 operations performed in connection with use of the stub information to invoke processing of the 

17 remote method or procedure. 

1 8 Detailed Description of an Illustrative Embodiment 

19 FIG. 1 is a schematic diagram of a computer network 10 including an arrangement for 

20 facilitating dynamic loading of "stub" information to enable a program operating in one address space 

21 to remotely invoke processing of a method or procedure in another address space. With reference 

22 to FIG. 1, computer network 10 includes a plurality of client computers 11(1) through 11(N) 

23 (generally identified by reference numeral 1 l(n)), a plurality of server computers 12(1) through 12(M) 
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1 (generally identified by reference numeral 12(m)), all of which are interconnected by a network 

2 represented by a communication link 14. In addition, the network 10 may include at least one 

3 nameserver computer 13, which may also be connected to communication link 14, whose purpose 

4 will be described below. As is conventional, at least some of the client computers 1 l (n) are in the 

5 form of personal computers or computer workstations, each of which typically includes a system unit, 

6 a video display unit and operator input devices such as a keyboard and mouse (all of which are not 

7 separately shown). The server computers 12(m) and nameserver computer 13 also typically include 

8 a system unit (also not separately shown), and may also include a video display unit and operator 

9 input devices. 

II The client computers 1 l(n), server computers 12(m) and nameserver computer 13 are all of 

1^ the conventional stored-program computer architecture. A ^stem unit generally includes processing, 

ti memory, mass storage devices such as disk and/or tape storage elements and other elements (not 
separately shown), including network interface devices 15(n), 16(m) for interfacing the respective 

f4 computer to the conmiunication link 14. The video display unit permits the computer to display 

f| processed data and processing status to the operator, and an operator input device enables the 

W operator to input data and control processing by the computer. The computers 1 l (n) and 12(m) and 

M 13 transfer information, in the form of messages, through their respective network interface devices 

F§ 1 5(n), 16(m) among each other over the communication link 14. 

19 In one embodiment, the network 10 is organized in a "client-server" configuration, in which 

20 one or more computers, shown in FIG. 1 as computers 12(m), operate as servers, and the other 

21 computers, shown in FIG. 1 as computers 1 l(n) operate as clients. In one aspect, one or more of the 

22 server computers 12(m) may, as "file servers," include large-capacity mass storage devices which can 

23 store copies of programs and data which are available for retrieval by the client computers over the 

24 communication link 13 for use in their processing operations. From time to time, a client computer 

25 1 l(n) may also store data on the server computer 12, which may be later retrieved by it (the client 

26 computer that stored the data) or other client computers for use in their processing operations. In 

27 addition, one or more of the server computers 12(m) may, as "compute servers," perform certain 
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1 processing operations in response to a remote request therefor from a client computer 1 ^n), and 

2 return the results of the processing to the requesting client computer 1 l(n) for use by them (that is, 

3 the requesting client computers 1 1 (n)) in their subsequent processing. In either case, the server 

4 computers may be generally similar to the client computers 1 l(n), including a system unit, video 

5 display unit and operator input devices and may be usable by an operator for data processing 

6 operations in a manner similar to a client computer. Alternatively, at least some of the server 

7 computers may include only processing, memory, mass storage and network interface elements for 

8 receiving and processing retrieval, storage or remote processing requests from the client computers, 

9 and generating responses thereto. It will be appreciated a client computer 1 l(n) may also perform 
W operations described herein as being performed by a server computer 12(m), and similarly a server 
|i computer 12(m) may also perform operations described herein as being performed by a client 
H computer 1 l(n). 

O The network represented by communication link 14 may comprise any of a number of ts^pes 

|4 of networks over which client computers 1 l(n), server computers 12(m) and nameserver computers 

tj 13 may communicate, including, for example, local area networks (LANs) and wide area networks 

rS (WANs) which are typically maintained within individual enterprises, the public telephony system, 

IJ the Internet, and other networks, which may transfer digital data among the various computers. The 

t8 network may be implemented using any of a number of communication media, including, for example, 

19 wires, optical fibers, radio links, and/or other media for carrying signals representing information 

20 among the various computers depicted in FIG. 1 . As noted above, each of the computers typically 

21 includes a networic interface which connects the respective computer to the communications link 14 

22 and allows it to transmit and receive information thereover. 

23 The invention provides a system for facilitating the obtaining and dynamic loading of "stub" 

24 information to enable a program operating in one address space to invoke processing of a remote 

25 method or procedure in another address space, which may be located on the same computer as the 

26 invoking program or on a different computer. The invention will be described in connection with 

27 programs provided in the Java™ programming language, as described in the Java language 
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1 specification, which are processed in connection with an execution environment which is provided 

2 by a Java virtual machine. The Java virtual machine, in turn, is specified in the Java virtual machine 

3 specification. As described in the Java language specification, programs in the Java programming 

4 language define "classes" and "interfaces." Classes are used to define one or more methods or 

5 procedures, each of which may be invoked by reference to an interface. A class may be associated 

6 with and extend a "super-class," and in that regard will incorporate all of the interfaces and methods 

7 of the super-class, and may also include additional interfaces and/or methods. A class may also have 

8 one or more sub-classes (and thus will comprise a super-class of each of its sub-classes), with each 
J sub-class incorporating and possibly extending their respective super-classes. 



P An interface provides a mechanism by which a set of methods may be declared. In that 

|( connection, an interface identifies each method that is declared by the interface by, for example, a 

M name, identifies the data type(s) of argument(s) that are to be provided for the method, the data 

ti type(s) of return values that are to be returned by the method, and identifiers for exceptions which 
can be thrown during processing of the method. A class may indicate that it implements a particular 

^ interface, and in that connection will include the program code which will be used in processing all 

1^ of the methods which are declared in the interface. In addition, different classes may indicate that 

|l they implement the same interface, and each will have program code which will be used in processing 

1 8 all of the methods which are declared in the interface, but the program code provided in each class 

19 to for use in processmg the methods may differ from the program code provided in the other classes 

20 which is used in processing the same methods; thus, an interface provides a mechanism by which a 

21 set of methods can be declared without providing an indication of the procedure which will be used 

22 in processing any of the methods. An interface may be declared independently of the particular class 

23 which implements the method or methods which can be invoked using the interface. In that regard, 

24 a class that invokes the method and a class that actually implements the method will not need to share 

25 a common super-class. 

26 During processing of a Java program, as described in the Java virtual machine specification, 

27 a client computer 1 l(n) provides an execution environment 20 for interpreting the Java program. The 
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1 Java virtual machine includera class loader 21^tHat, under control of a control module 19, can 

2 dynamically link instances of classes, generally identified in FIG. 1 by reference numeral 22, into the 

3 running program's execution environment while the program is being executed. In that operation, 

4 the control module 19 effectively enables the class loader to retrieve uninstantiated classes, which 

5 generally identified by reference numeral 23, instantiate them and link them as class instances 22 into 

6 the execution environment's address space at the Java program's run time as the methods which the 

7 respective classes 23 implement are called. In addition, the class loader 21 can discard ones of the 

8 class instances 22 when they are not needed or to conserve memory. It will be appreciated that, if 

9 a class instance 22 has been discarded, it may be reloaded by the class loader 21 at a later point if it 
^ is then needed. 

IJ The invention provides an arrangement which facilitates the remote invocation, by a program 

Q executing in an execution environment 20 by a client computer 1 l(n), of methods implemented by 

classes on a server computer 12(m). In executing a method, the server computer 12(m) will also 

14 provide an execution environment 24 for processing, under control of a control module 28, the Java 

2 method. In that operation, the Java virtual machine which provides the execution enviromnent 21 

includes a class loader 25 (which may be similar to the class loader 21) that, under control of the 

W control module 28, can dynamically link an instance of the class 26, to enable the method to be 

1 8 processed in the execution environment 24, and instances of other classes (also generally represented 

19 by reference numeral 26) which may be needed to process the remotely-invoked method. In that 

20 operation, the control module 28 effectively enables the class loader 25 to retrieve an uninstantiated 

21 class for the method to be invoked, fi^om a plurality of uninstantiated classes which are generally 

22 identified by reference numeral 27, instantiate it (that is, the uninstantiated class which provides the 

23 method to be invoked) and link it as a class instance 26 into the execution environment. In addition, 

24 the class loader 25 can discard the class instances 26 when processing of the method has terminated. 

25 It will be appreciated that, if class instances 26 has been discarded, it may be reloaded by the class 

26 loader 25 at a later point if it is then needed. 
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1 The stmcture of nameserver computer 13, if provided, is generally similar to that of the server 

2 computer 12(m), and will not be separately described. 

3 To facilitate remote invocation of a method, the control module 19 of the client computer's 

4 execution environment 21 makes use of one or more stub class instances generally identified by 

5 reference numeral 30 v^hich are provided as part of the execution environment 2 1 in which the various 

6 class instances 22, including the class instance which is invoking the remote method, are being 

7 processed. Each stub class instance 30 is an instance of an uninstantiated stub class 31, which the 

8 server computer 12(m) may maintain for the various class instances 26 and uninstantiated classes 27 
;g which the server computer 12(m) has "exported," that is, which the server con^uter 12(m) makes 
ffl available to client computers 1 l(n) for use in remote invocation of methods provided thereby. An 
tM uninstantiated stub class 3 1 includes declarations for the complete set of interfaces for the particular 
\^ remote unmstantiated class 27 which implements the remote method to be invoked, and also provides 
M or invokes methods which fedlitate accessing of the remote method(s) which are implemented by the 
M remote class. The uninstantiated stub class 31, when it is instantiated and provided to the execution 

environment 20 of the client computer 1 l(n) as a stub class instance 30, effectively provides the 

15 information which is needed by the control module 19 of the execution environment 20 of the 

S invddng Java program, so that, when a remote method that is implemented by its associated class is 

18 invoked by a Java program running in a particular execution environment, the remote method will 

19 be processed and the return value(s) provided to tHe invoking Java program. In one embodiment, the 

20 arrangement by which the stub class instance may be provided to the execution environment 20 is 

21 similar to that described in the aforementioned Waldo, et al., patent application. 

22 In addition, the server computer 12(m) provides a skeleton 32, which identifies the particular 

23 classes and n^hods which have been exported by the server computer 12(m) and information as to 

24 how it (that is, the server computer 12(m)) may load the respective classes and initiate processing of 

25 the particular methods pro^dded thereby. 

26 When a class instance invokes a remote method maintained by a server computer 12(m), it 

27 will provide values for various parameters to the stub class instance 30 for the remote method, which 
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1 values the remote method will use in its processing. If the remote method is implemented on the 

2 same computer as the invoking Java program, when the invoking Java program invokes a remote 

3 method, the computer may establish an execution environment, similar to the execution environment 

4 20, enable the execution environment's class loader to load and instantiate the class which implements 

5 the method as a class instance similar to class instances 22, and process the remote method using 

6 values of parameters which are provided by the invoking class instance in the remote invocation. 

7 After processing of the method has been completed, the execution environment in which the remote 

8 method has been processed will pro\dde the results to the stub class instance 30 for the remote 

9 method that was invoked, which, in turn, will provide to the particular class instance 22 which 
M invoked the remote method. 

W Similar operations will be performed if client computer 1 l(n) and server computer 12(m) are 

i| implemented on different physical computers. In that case, in response to a remote invocation, the 

M client computer 1 l(n) that is processing the invoking class instance 22, under control of the control 

M module 19 for the execution environment 10 for the invoking class instance 22, will use the 

Ip appropriate stub class instance 30 to communicate over the network represented by the 

1^ communication link 14 with the server computer 12(m) which implements the remote method to 

ll enable it (that is, the server computer 12(m)) to estabUsh an execution environment 24 for the class 

18 which implements the remote method, and to use the class loader 25 to load an instance of the class 

19 as a class instance 26. In addition, the client computer 1 l(n), also using the appropriate stub class 

20 instance 30, \^dU_proYide^Jmy re^ values to the serve^^ over the 

21 network 14. Thereafter, the server computer 12(m) will process the remote method using parameter 

22 values so provided, to generate result value(s) which are transferred over the network to the client 

23 computer 1 l(n), in particular to the appropriate stub class instance 30. The client computer 1 l(n) 

24 will, after it receives the result value(s) from the network, provide them to the invoking class instance 

25 22 for its processing. 

26 In any case, when the control module 19 of the client computer's execution environment 20 

27 determines that a reference to the remote object has been received, if it determines that the stub class 
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1 instance 30 is not present when it receives the reference, it will attempt to obtain the stub class 

2 instance 30 from, for example, the server computer 12(m) which implements the remote method, and 

3 enable the stub class instance 30 to be dynamically loaded in the execution environment 20 for the 

4 invoking class instance 22. A reference to the remote object may be received, for example, either as 

5 a return value of another remote method invocation or as a parameter that is received^^^ 

6 remote method invocation. The stub class instance may be dynamically loaded into the execution 

7 environment in a manner similar to that used to load class instances 22 in the execution environment 

8 22. The execution environment 20 is provided with a stub class loader 33 which, under control of the 

9 control module 19, will attempt to find and load the stub class instances 30 as required by the class 
BO instances 22 processed in the execution environment. The location of a particular server computer 
fl 12(m) that maintains the class that implements a method to be invoked remotely may be inchided in 
S the call from the invoking class instance or may be made known to the stub class loader 33 through 
jg another mechanism (not shown) mmntained by the client computer 1 l(n). 

14 However, if the stub class loader 33 is not otherwise notified of which server computer 12(m) 

t$ maintains the class which implements a method which may be invoked remotely, it may use the 

re nameserver computer 13 to provide that identification. The identification may comprise any identifier 

fl which may be used to identify a server computer 12(m) or other resource which is available on the 

f S network 14 and to which tte server computer 12(m) can respond. Illustrative identifiers include, for 

19 example, a network address which identifies the server computer and/or resource, or, if the network 

20 14 is or includes the Internet, an identifier to, for example, a World Wide Web resource which may 

21 provide the identification or a "uniform resource locator" ("URL") which provides a uniform 

22 mechanism for identifying resources that are available over the Internet. The server computer 12(m) 

23 which implements the remote method, in response to a request from the client computer 1 l(n) will 

24 provide stub class mstance 30 which the client computer ll(n) may load into the execution 

25 environment 21 to thereafl;er enable the remote invocation to be initiated. 

26 As noted above, if the stub class loader 33 does not know which server computer 12(m) 

27 implements the remote method which may be invoked (and thus does not know which computer is 
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1 to provide the stub class code for the remote invocation), it may, under control of the control module 

2 19, obtain the identification fi*om the nameserver computer 13, In that operation, the stub class 

3 loader 33 may use a previously-provided default stub class which is provided for use in such cases. 

4 The default class stub, when used by the invoking Java program, enables the computer that is 

5 processing the invoking Java program to communicate with the nameserver computer 13 to obtain 

6 information which can be used in invoking the remote method. This operation is essentially the same 

7 as the invocation of a remote method to be processed by the nameserver computer 13, with the 

8 remote method including a parameter identifying the class and method to be remotely invoked, and 

9 enabling the nameserver computer 13 to provide the identification of a server computer 12(m) which 
to can process the method to the requesting client computer 1 l(n) and other information which may be 
S helpfijl in communicating with the server computer 12(m) and invoking the particular method. It will 
tl be appreciated that the nameserver computer 13 will maintain a table (not separately shovra) of 
ti "exported*' resources, that is, resources, such as classes and methods, that are available to client 

computers 1 l(n) connected to the network 14, and information, such as the identifications of the 
particular server computers 12(m) which provide those resources, which will be usefiil to the client 

M computers 1 l (n) in making use of the exported resources. 

IS It will be appreciated that the nameserver computer 1 3 may create and maintain the exported 
resource table in a number of ways that are known in the art. For example, the nameserver computer 

19 13 may periodically broadcast requests for exported resource information over the network 14, to 

20 which the various server computers 12(m) which maintmn exported resources may respond; in that 

21 case, the nameserver computer 13 may establish its exported resource table based on the responses 

22 firom the server computers 12(m) . Alternatively, each of the various server computers 12(m) which 

23 maintains an exported resource may periodically broadcast information as to the exported resources 

24 which it maintains, and the nameserver computer 13 can update its exported resource table based on 

25 the broadcasts fi'om the server computer. In addition, the nameserver computer's exported resource 

26 table may be established by a system operator and may be fixed until he or she updates it. 
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1 In any case, the information provided by the nameserver computer 1 3 in response to a request 

2 initiated by the default stub would include such information as, for example, the identification of a 

3 computer 12(m) which can provide a class which implements the remote method to be invoked, 

4 particular information which the computer (that is, the computer which implements the remote 

5 method) will require to provide the required stub class code, and the like. After receiving the 

6 information fi^om the nameserver computer 13, the computer 1 l(n) that is processing the invoking 

7 Java program may, under control of the control module 19, use the information communicate with 

8 the computer (that is, the computer which implements the remote method) to obtain the stub class, 

9 and may thereafter invoke the method as described above. 

fi With this background, the operations performed by client computer 1 l(n), server computer 
I2(m) and, if necessary, nameserver 13 in connection with obtaining and dynamic loading of a stub 

fM class mstance when a reference to a remote method is received will be described in connection with 

0^ W the flow chart depicted in In addition, operations performed by the client computer 1 l(n) and 

f4 server computer in connection with remote invocation of a method using the stub class instance will 

% my 3ft 

0^ be described in connection with the flow chart depicted in HGr*. With reference initially to FIG. 

^16 2, the execution environment control module 19 will, when it receives a reference to a remote 

|i method, will initially determine whether an appropriate stub class instance is present in the execution 

18 environment 20 to facilitate invocation of the remote method (step 100). If the control module 19 

19 determines that such a stub class instance 30 for the remote method is present in the execution 

20 environment, it may continue other operations (step 101), However, if the control module 19 

21 determines in step 101 that such a stub class instance is not present in the execution environment 20 

22 for the remote method, the control module 19 will use the stub class loader 33 to attempt to locate 

23 and load a stub class instance 30 for the class to process the remote method. In that case, the control 

24 module 19 will initially determine whether the invocation fi^om the class instance 22 included a 

25 resource locator to identify the server computer 12(m) or other resource which maintains the class 

26 for the method to be invoked, or whether it (that is, the control module 19) or the stub class loader 

27 33 otherwise are provided with such a resource locator (step 102). If the control module 19 makes 

28 a positive determination in that step, it will sequence to step 103 to enable the stub class loader 33 
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1 ip initiate cjonamunications with identified server computer 1 2(m) to obtain stub class instance for the 

2 class and method to be invoked (step 103). When the stub class loader 33/feceives<|he stub class 

.^-..r'"" \ ' 

3 mstance 30 from the server computer 12(m), it wiU(loadthe' stub class instance 30 into execution 

4 environment 20 for the class instance 21 which initiated the remote method invocation call in step 100 

5 (step 104). After the stub class instance 30 for the referenced remote method has been loaded in the 

6 execution environment, the method can be invoked as will be described below in connection with 

(k^ 7 HGr*. 

A 

8 Returning to step 102, if the control module 19 determines that the invocation from the class 

21 instance 22 did not include a resource locator to identify the server computer 1 2(m) or other resource 

fH which maintains the class for the method to be invoked, and fiuther that it (that is, the control module 

t| 19) or the stub class loader 33 is not otherwise provided with such a resource locator, a "class not 

11 found" exception may be indicated, at which point the control module 19 may call an exception 

l|| handler. The exception handler may perform any of a number of recovery operations, including, for 

14 example, merely notifying the control module 19 that the remote method could not be located and 

iM allow it to determine subsequent operations. 

r| Alternatively, the control module 19 may attempt to obtain a resource locator from the 

¥i nameserver computer 13 or other resource provided by the network 14 (generally represented in FIG. 

18 1 by the nameserver computer 13), using a call to, for example, a default stub class instance 30. The 

19 call to the default stub class instance 30 \^dll include an identification of the class and method to be 

20 invoked and the name of the nameserver computer 13 (m) . Using the default stub class instance 30, 

21 the control module 19 will enable the computer 1 l(n) to initiate communications with nameserver 

22 computer 13 to obtain an identifier for a server computer 12(m) which maintains the class and method 

23 to be invoked (step 1 10). The communications from the default stub class instance 30 will essentially 

24 correspond to a remote method invocation, with the method enabling the nameserver computer to 

25 provide the identification for the server computer 12(m), if one exists associated with the class and 

26 method to be remotely invoked, or alternatively to provide an indication that no server computer 

27 12(m) is identified as being associated with the class and method. During the communications in step 
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1 110, the default stub class interface 30 will provide, as a parameter value, the identification of class 

2 and method to be invoked. 

3 In response to the communications from the default stub class instance 30, the nameserver 

4 computer 13 will process the request as a remote method (step 111), with the resuh information 

5 comprising the identification for the server computer 12(m), if one exists that is associated with the 

6 class and method to be remotely invoked, or alternatively an indication that no server computer 1 2(m) 

7 is identified as being associated with the class and method. Afler finishing the method, the 

8 nameserver computer 13 will initiate communications with the defauU stub class instance 30 to 
^ provide the result information to the default stub class instance 30 (step 112). 

After receipt of the result information from the nameserver computer 13, the default stub class 
P instance, under control of the control module 19, will pass result information to the stub class loader 
Q 33 (step 1 13), Thereafter, the stub class loader 33 determines whether the result information from 
P3 the nameserver computer comprises the identification for the server computer 12(m) or an indication 
tS that no server computer 12(m) is identified as bemg associated with the class (step 1 14), If the stub 
class loader 33 determines that the result information comprises the identification for the server 
i| computer 12(n^, it (that is, the stub dass loader 33) will return to step 101 to initiate communication 
W with the identified server computer 12(m) to obtain stub class instance for the class and method that 

18 may be invoked. On the other hand, if the stub class loader 33 determines in step 114 that the 

19 nameserver computer 13 had provided an indication that no server computer 12(m) is identified as 

20 being associated with the class and method that may be invoked, the "class not found" exception may 

21 be indicated (step 1 15) and an exception handler called as described above. 

22 As noted above, the stub class instance 30 retrieved and loaded as described above in 
0^ 23 connection with Fi&rS may be used in remote invocation of the method. Operations performed by 

24 the client computer 1 l(n) in connection with remote invocation of the method will be described in 

SLy 25 connection with the flow chart in FIGr*. As depicted in FIG. 3 when a class instance 22 invokes 

^ n 

26 a method, the control module 19 may initially verify that a stub class instance 30 is present in the 

27 execution environment for remote method to be invoked (step 120). If a positive determination is 
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1 made in step 120, the stub class instance 30 will be used for the remote invocation, and in the remote 

2 invocation will provide parameter values which are to be used in processing the remote method (step 

3 121). Thereafter, the stub class instance 30 for the remote method that may be invoked will be used 

4 to initiate communications Avith the server computer 1 2(m) which maintains the class for the remote 

5 method (step 122), in the process, the passing parameter values which are to be used in processing 

6 the remote method will be passed. It will be appreciated that, if the server computer 12(m) which 

7 is to process the method is the same physical computer as the client computer 12(n) which is invoking 

8 the method, the communications can be among execution environments which are being processed 

9 within the physical computer. On the other hand, if the server computer 12(m) which is to process 
the method is a different physical computer from that of the client computer 12(n) which is invoking 

W the method, the communications will be through the client computer's and server computer*s 

© respective network interfaces 15(n) and 16(m) and over the network 14. 

33 In response to the communications from the stub class instance in step 122, the server 

|4 computer 12(m), if necessary establishes an execution environment 24 for the class which maintains 

1§ the method that may be invoked, and the uses the information provided by the skeleton 32 to create 
a class instance 26 for that class (step 123). Thereafter, the server computer 12(m), under control 

if of the control module 28, will process the method in connection with parameter values that were 

1 8 provided by stub class instance 30 (step 124). After completing processing of the method, the server 

19 computer 12(m), also under control of the control module 28, will initiate communications with the 

20 client computer's stub class instaiice 30 to provide result information to the stub class instance (step 

21 1 25). In a manner similar to that described above in connection with step 1 02, if the server computer 

22 12(m) wluch processed the method is the same physical computer as the client computer 12(n) which 

23 invoked the method, the communications can be among execution environments 24 and 20 which are 

24 being processed within the physical computer. On the other hand, if the server computer 12(m) 

25 which processed the method is a different physical computer from that of the client computer 12(n) 

26 which is invoking the method, the communications will be through the server computer's and client 

27 computer's respective network interfaces 16(m) and 1 5(n) and over the network 14. After the stub 

28 class instance 30 receives the result information from the server computer, it may provide result 
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1 information to the class instance 22 which initiated the remote method invocation (step 126), and that 

2 class instance 22 can continue processing under control of the control module 19. 

3 Returning to step 120, if the control module 19 determines in that step that it does not have 

4 a stub class instance 30 that is appropriate for the remote method that may be invoked, it may at that 

5 point call an exception handler (step 127) to perform selected error recovery operations. 

6 The invention provides a number of advantages. In particular, it provides a new system and 

7 method for facilitating dynamic loading of a stub which enables a program that is operating in one 

8 execution environment to remotely invoke processing of a method in another execution environment, 
3 so that the stub can be loaded by the program when it is run and needed. In systems in which stubs 
M are compiled with the program, and thus are statically determined when the program is compiled, 
Itf they (the stubs) may hnplement subsets of the actual set of remote interfaces which are supported by 

the remote references that is received by the program, which can lead to errors and ineflSciencies due 

Ip to mismatches between the stub that is provided to a program and the requirements of the remote 

|4 procedure that is called when the program is run. However, since, in the dynamic stub loading system 

]^ and method, the stub that is loaded can be obtained from the particular resource which provides the 

16 remote method, it (the stub) can define the exact set of interfaces to be provided to the invoking 

]J program at run time, thereby obviating run-time incompatibilities which may resuh from mis-matches 

1 8 between the stub that is provided and the requirements of the remote method that is invoked. 

19 It will be appreciated that a number of modifications may be made to the arrangement as 

20 described above. For example, although the execution environment 20 has been described as 

21 obtaining and loading stub class instances to facilitate invocation of remote methods when references 

22 to the remote methods are received, it will be appreciated that stub class instances may instead be 

23 obtained and loaded when the remote methods are initially invoked. Obt^ning and loading of the 

24 stub class instance for a remote method when a reference thereto is received will have the advantages 

25 that 0 the stub class instance will be present in the execution environment when the remote method 

26 is actually invoked, and (ii) if the appropriate stub class instance can not be located, the program or 

27 an operator may be notified at an early time. On the other hand, obtaining and loading of the stub 
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1 class instance for a remote method when the method is to be invoked may result in a delay of the 

2 invocation until the correct stub class instance can be found, if the method is in fact not invoked even 

3 if a reference to it is received the stub class instance may not need to be located and loaded. 

4 It will be appreciated that a system in accordance with the invention can be constructed in 

5 whole or in part from special purpose hardware or a general purpose computer system, or any 

6 combination thereof, any portion of which may be controlled by a suitable program. Any program 

7 may in whole or in part comprise part of or be stored on the system in a conventional manner, or it 

8 may in whole or in part be provided in to the system over a network or other mechanism for 
f§ transferring information in a conventional manner. In addition, it will be appreciated that the system 
W may be operated and/or otherwise controlled by means of information provided by an operator using 
W operator input elements (not shown) which may be connected directly to the system or which may 
i2 transfer the information to the system over a network or other mechanism for transferring information 
PI in a conventional manner, 

f| The foregoing description has been limited to a specific embodiment of this invention. It will 

f§ be apparent, however, that various variations and modifications may be made to the invention, with 

P the attainment of some or all of the advantages of the invention. It is the object of the appended 

97 claims to cover these and such other variations and modifications as come within the true spirit and 

18 scope of the invention. 

19 What is claimed as new and desired to be secured by Letters Patent of the United States is: 
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Claims 

^y^^ connection with a remote method invocation system, a stub retrieval andlpfading 

2 subsystem for controlling the retrieval and loading of a stub for a remote method into ariexecution 

3 environment to facilitate invocation of the remote method by a program executingin said execution 

4 environment, the stub retrieval subsystem comprising: 

5 A. a stub retriever for initiating a retrieval of said stub; and y/^ 

6 B. a stub loader for, when said stub is received by said stub/etriever, loading said stub into said 

©cecution environment, thereby to make the stub avaikble for use in remote invocation of said 
CI remote method. / 



=3 2. A stub retrieval and loading subsystem as defined in claim 1 further including a remote method 

Q reference detector for detecting whe^^ a remote method reference has been received in said 

S execution environment, the stub rrtnever initiating retrieval of said stub when the remote method 
reference detector detects that remote method reference has been received in said execution 

iS environment. / 

1 3. A stub retrievamnd loading subsystem as defined in claim 1 further including a remote method 

2 invocation control for controlling invocation of said remote method, said stub retriever initiating 

3 retrieval of s^ stub when the remote method is invoked. 

1 4. A4ub retrieval and loading subsystem as defined in claim 1, the remote method invocation system 

2 fimher including a server for processing said remote method in response to a processing request 
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therefor, the server ftirther providing said stub in response to a re^ievgf request from said stub 
retriever. 




5. A stub retrieval mUtSading subsystem as defined in claim 4 in which server provides a separate 
address spactH^processing said remote method from an address space provided by said execution 
enymynment. 



6. A stub retrieval and loadingS^ubsystem as defined in claim 5 in which the address space provided 
by said server and the address spacbsprovided by said execution environment are provided by separate 
computers. 



^7. A stub retrieval and loading subsystem as defined in claim 4, fixrther comprising a remote s^ 
identifier for providing a server identification for identifying said server. 



8. A stub retrieval and loading subsystem as defined in ^krfv further including a remote method 
reference detector for detecting whether a remofe^ethod reference has been received in said 
execution environment, the remote method mfemice including a remote method server identifier, the 
remote server identifier using the remefe method server identifier as the server identification. 



9, A stub retriev^^d loading subsystem as defined in claim 7 fiirther including a remote method 
invocation co^ol for providing a remote method invocation identification for controlling invocation 
of said temote method, the remote method invocation providing a remote method server identifier, 
tlp^emote server identifier using the remote method server identifier as the server identification. 
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1 10. A stub retrieval and loading subsystem as defined in claim 7, the remote method invpcmion 

2 system forther including a nameserver for providing a said server identification, saidjetm)te server 

3 identifier initiating communication with said nameserver to obtmn the serv^^id€ntification for said 

4 remote method. 

1 11. For use in connection with a remote methodjrivocation method, a stub retrieval and loading 

2 method for facilitating the retrieval and loading of a stub for a remote method into an execution 

5 environment to fecilitate invocation ofji© remote method by a program executing in said execution 
\A environment, the stub retrievalpdmod comprising the steps of: 

J A. a stub retrieval;*^ for initiating a retrieval of said stub; and 

S B. a stub Jmding step for, when said stub is received, loading said stub into said execution 
y emqfonment, thereby to make the stub available for use in remote invocation of said remote 

/method. 

1 J^^12. A stub retrievahMd loading method as defined in claim 11 further including a remote method 

2 ( reference detection step fei;detecting whether a remote method reference has been received in said 

3 execution enwonment, the stub^trieval step including the step of initiating retrieval of said stub 

4 when a remote method reference hasten received in said execution environment. 



1 
2 
3 



13. A stub retrieval and loading method as defined in^ckim 1 1 further including a remote method 
invocation control step for controlling invocation of said r^iiote method, said stub retrieval step 
including the step of initiating retrieval of said stub when the rembte method is invoked. 
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^^^^^M. A stub retrieval and loa^g method as defined in clmmJJ^Jfee-^^ system 
^ 2 further meluding a server for pro^s^ng-is^dlimo^ response to a processing request 

3 therefor, the s^jjef-filffEer providing said stub in response to a retrieval request fi-om said stub 

1 ^/-/S. A stub retrieval and loading method as defined in claim 14 in which server provides a separate 

A ^ / address sp^e for processing said remote method fi-om an address space provided by said execution 

3 environmentX 

16. A stub retrieval and loading method as defined in claim 15 in which the address space provided 

2 by said server and the address^pace provided by said execution environment are provided by separate 

1 computers. \ 

1 17. A stub retrieval and loading method\s defined in claim 14, fiirther comprising a remote server 

2 identification step for providing a server identification for identifying said server, 

1 18. A stub retrieval and loading method as defined in <^aim 17 fiirther including a remote method 

2 reference detection step for detecting whether a remote method reference has been received in said 

3 execution environment, the remote method reference including aNremote method server identifier, the 

4 remote method server identifier being used during the remote methbd reference detection step as the 

5 server identification. \ 
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19. A stub retrieval and loading method as defined in claim 17 further including a remote method 
invocation control step for providing a remote method invocation identification for controlling 
invocation of said remote method, the remote method invocation providing a remote method server 
identifier, the remote method server identifier being used during the remote method reference 
detection step as the server identification. 



20. A stub retrieval and loading subsystem as defined in claim 17, the remote method invocation 
system fiirther including a nameserver for providing a said server identification, said remote server 
identifier initiating communication with said nameserver to obtain the server identification for said 
remote method. 

21. For use in connection with a remote method invocation system, a stub retrieval and loading 
computer program product for controlling a computer to, in turn, control the retrievd^andloading 
of a stub for a remote method into an execution environment to facilitate inypeartion of the remote 
method by a program executing in said execution environment, the s^^b-f^eval computer program 
product comprising a computer-readable medium having ei^pd^d thereon: 

A stub retriever code devices to enable said opdputer to initiate a retrieval of said stub; and 

B. a stub loader code devices to enaWp^d computer to, when said stub is received, loading said 
stub into said execution em^nment, thereby to make the stub available for use in remote 
invocation of said r^^idie method, 

22. A stub mtfieval and loading computer program product as defined in claim 21 further including 
remot^/method reference detector code devices for enabling said computer to detect whether a 
T^^tQ method reference has been received in said execution environment, the stub retriever code 
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4 deviGes enabling said computer to initiate retrieval of said stub when the remote metho^feference 

5 detector code devices enable said computer to detect that a remote method rafi^nce has been 

6 received in said execution environment. 

1 23, A stub retrieval and loading computer program productjas defined in claim 21 further including 

2 remote method invocation control code devices for en^^g said computer to control invocation of 

3 said remote method, smd stub retriever code de^di^ enabling said computer to initiate retrieval of 

4 said stub when the remote method is invoked^ 



^ 24. A stub retrieval and loading computer program product as defined in claim 21, the remote method 

j2 invocation system fiarther if^luding a server for processing said remote method in response to a 

J processing request th^eror, tiie server further providing said stub in response to a retrieval request 

14 fi'om said stub retridver. 

^ 25. A stub retrieval and loading computer program product as defined in claim 24 in which server 

2 proyides a separate address space for processing said remote method fi'om an address space provided 

3 Yj said execution environment. 

A stub retrieval and loading co™uter program product as defined in claim 25 in which the 

2 ( address space provided by said server and tn&saddress space provided by said execution environment 

3 are provided by separate computers. \. 



3 identij^Jig^d server. 
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2 remote server id^fieF-cd^devices for enabling said computer to provide a server identification for 

3 identi^ng^d server, 

1 o^\28. A stub retrieval and loading computer program product as defined in claim 27 further including 

r \ 

2 ^ I remote method reference d^ector code devices for enabling said computer to detect whether a 

3 remote method reference has aeen received in said execution environment, the remote method 

4 reference including a remote method server identifier, the remote server identifier code devices 
I J enabling said computer to use the remqte method server identifier as the server identification. 

/^9. A stub retrieval and loading computer program product as defined in claim 27 fiirther in^jjdifig 
2 / remote method invocation control code devices for enabling smd computer to prasi^de a remote 
9 method invoc^ion identification for controlling invocation of said remote me^od^e remote method 
ft invocation providing a remote method server identifier, the remote-^s^er identifier code devices 
% enabling said computer to use the remote method server idi^t^^r as the server identification. 

1 30. A stub retrieval and loading computer pxigram product as defined in claim 27, the remote method 

2 invocation system fiirther including^ nameserver for providing a said server identification, said 

3 remote server identifier code^vices enabling said computer to initiate communication with said 

4 nameserver to obtain the^rver identification for said remote method. 

1 31. For i^e in connection with a remote method invocation system, a stub retrieval and loading 

2 subsj^m for controlling the retrieval and loading of a stub for a remote method into an execution 
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3 environment to fedlitate invocation of the remote method by a program executing in execution 

4 environment, the stub retrieval subsystem comprising: 

5 A. a computer; and X 

6 B. a control arrangement for controlling said computer, said control arrangement comprising: 

7 i. a stub retrieval module for controlling said computer to initiate a retrieval of said stub; 

8 and / 

9 ii. a stub loader module for controlling saidxomputer to, when said stub is received in 
ffi response to said stub retrieval modide4oad said stub into smd execution environment, 
p thereby to make the stub availaole for use in remote invocation of said remote 
jS method. / 



32, A control arrangement for use in jronnection with a computer to control the retrieval and loading 

^ of a stub for a remote method info an execution environment to facilitate invocation of the remote 

y3 method by a program executingin said execution environment, said control arrangement comprising: 

"4 i, a stub retrieval ni^ule for controlling said computer to initiate a retrieval of said stub; and 

5 ii, a stub loader niodule for controlling said computer to, when said stub is received in response 

6 to said stubretrieval module, load said stub into said execution environment, thereby to make 

7 the stub/available for use in remote invocation of said remote method. 

1 33. A ^stem for distributing code stored on a computer readable medium and executable by a 

2 compdter, the code including a plurality of modules each configured to control the computer to 

3 facilitate the retrieval and loading of a stub for a remote method into an execution environment to 
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facilitate invocation of the remote method by a program executing in said 
system comprising: 



ronment, said 



a stub retrieval module for com 




said computer to initiate a retrieval of said stub; and 



a stub loader moddle for controlling said computer to, when said stub is received in response 
to said^b retrieval module, load said stub into said execution environment, thereby to make 
the stub available for use in remote invocation of said remote method. 
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Abstract Of The Disclosure 



A stub retrieval and loading subsystem is disclosed for use in connection with a remote 
method invocation system. The stub retrieval and loading subsystem controls the retrieval and 
loading of a stub for a remote method, into an execution environment, to facilitate invocation of the 
remote method by a program executing in the execution environment. The stub retrieval subsystem 
includes a stub retriever for initiating a retrieval of the stub and stub loader for, when the stub is 
received by the stub retriever, loading the stub into the execution enwonment, thereby to make the 
stub available for use in remote invocation of the remote method. In one embodiment, the stub 
retrieval and loading subsystem effects the retrieval and loading for a program operating in one 
address space provided by one computer, of stub class instances to effect the remote invocation of 
methods which are provided by objects operating in another address space, which may be provided 
by the same computer or a different computer. 
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NO 



100. EXECUTION ENVIRONMENT CONTROL 
DETERMINES WHETHER IT HAS A STUB CLASS 
APPROPRIATE FOR THE REMOTE METHOD FOR 
WHICH IT HAS A REFERENCE 

I 

YES 



FIG. 2 



i 



101. CONTINUE 



1 



NO 



102. CONTROL MODULE DETERMINES WHETHER 
INVOCATION INCLUDED A RESOURCE IDENTIFIER 
OR IF A RESOURCE IDENTIFIER FOR THE CALL IS 
OTHERWISE PROVIDED 



I 

YES 



103. CONTROL MODULE ENABLES STUB CLASS 
LOADER TO INITIATE COMMUNICATIONS WITH 
IDENTIFIED SERVER COMPUTER TO OBTAIN STUB 
CLASS INSTANCE FOR THE CLASS AND METHOD TO | 
^E INVOKED 



I 



104. WHEN STUB CLASS LOADER RECEIVES STUB 
CLASS INSTANCE, CONTROL MODULE LOADS IT 
INTO EXECUTION ENVIRONMENT 



0 



0 



F I a 2 (CONT. A) 



110. CONTROL MODULE USES STUB CLASS 
LOADER IS CALLED TO, IN TURN, CALL DEFAULT 
STUB CLASS INSTANCE IS TO LOCATE 
APPROPRIATE SERVER COMPUTER, INCLUDING 
IDENTIFICATION OF CLASS AND METHOD TO BE 
^OKED 



111. NAMESERVER COMPUTER PROCESSES 
COMMUNICATIONS FROM DEFAULT STUB CLASS 
INSTANCE AS A REMOTE METHOD INVOCATION, TO 
OBTAIN RESULT INFORMATION 



112. NAMESERVER COMPUTER INITIATES 
COMMUNICATIONS TO PROVIDE THE RESULT 
INFORMATION TO THE DEFAULT STUB CLASS 
INSTANCE 



0 



HI 
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0 



113. RESULT INFORMATION IS PROVIDED TO STUB 
CLASS LOADER 



RESOURCE 
IDENTIFIER 



114. STUB CLASS LOADER DETERMINES WHETHER 
RESULT INFORMATION IS A RESOURCE IDENTIFIER 
OR AN INDICATION THAT NO RESOURCE IDENTIFIER 
EXISTS FOR THE CLASS AND METHOD 

V 



NO RESOURCE 
IDENTIFIER 



FIG. 3 



120. EXECUTION ENVIRONMENT CONTROL VERIFIES 
THAT IT HAS STUB CLASS INSTANCE FOR REMOTE 
METHOD WHICH HAS BEEN INVOKED 



YES 



i 



121. CALL INTERFACE PROVIDED BY STUB CLASS 
INSTANCE TO INVOKE REMOTE METHOD 
PROVIDING PARAMETER VALUES WHICH ARE TO BE | 
USED IN PROCESSING THE REMOTE METHOD 



122. STUB CLASS INSTANCE FOR REMOTE METHOD 
TO BE INVOKED INITIATES COMMUNICATIONS WITH 
SERVER COMPUTER WHICH MAINTAINS CLASS FOR 
REMOTE METHOD, IN THE PROCESS PASSING 
PARAMETER VALUES WHICH ARE TO BE USED IN 
yPROCESSING THE REMOTE METHOD 



123. SERVER COMPUTER ESTABLISHES AN 
EXECUTION ENVIRONMENT FOR METHOD TO BE 
INVOKED, USES INFORMATION PROVIDED BY 
SKELETON TO CREATE A CLASS INSTANCE FOR 
THE CLASS WHICH MAINTAINS THE METHOD TO BE 
INVOKED 



0 
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124. SERVER COMPUTER PROCESSES THE METHOD 
IN CONNECTION WITH PARAMETER VALUES 
PROVIDED BY STUB CLASS INSTANCE 



125. SERVER COMPUTER INITIATES 
COMMUNICATIONS WITH THE STUB CLASS 
INSTANCE TO PROVIDE RESULT INFORMATION TO 
THE STUB CLASS INSTANCE 



126. STUB CLASS INSTANCE RECEIVES RESULT 
AND PROVIDES RESULT INFORMATION TO CALLING 
CLASS INSTANCE 
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Citizenship United States of America 

Post Office Address: 9 Northwoods Road 
Groton, MA 01450 
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Residence: 1 55 Ruby Road 
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Citizenship United States of America 

Post Office Address: 155 Ruby Road 

Dracut, MA 01826 
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Residence: 4 Briarwood Lane 
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Attorney Docket No. P1091 

Citizenship United States of America 

Post Office Address: 4 Briarwood Lane 

Burlington, MA 01803 
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